The company said it would replace affected customers' certificates with free certificates obtained through partners. However, its announcement did not identify those partners or specify a date for completing its exit from the global SSL/TLS certificate business.
Six of the eight affected intermediate certificates were used to issue website Transport Layer Security (TLS) certificates. Google Chrome is set to stop trusting the eMudhra root certificate above them, emSign ECC Root CA - G3. The change is expected to reach users on the morning of October 27, Pacific time.
Mozilla had already decided on October 20 to stop trusting the same root certificate in Firefox. Removing a root certificate from a browser's trusted list also affects legitimate certificates issued beneath it, potentially requiring website operators to replace otherwise valid certificates.
According to Chrome's count of public Certificate Transparency (CT) logs, approximately 30,800 unexpired certificates chained to the affected root remained as of October 21. Of these, 99.9% had been issued through InCommon, the certificate service established by Internet2 for the higher education community. InCommon migrated the service to eMudhra's CertiNext platform between April and July this year.
Google has instructed website operators whose certificates chain to the affected root to "must immediately acquire and install a new TLS certificate from another PKI hierarchy included in the Chrome Root Store."
Until the transition is completed, eMudhra said its G1 RSA root certificates would continue serving customers. The G1 hierarchy is separate from the affected ECC root. However, Chrome is still evaluating whether to retain eMudhra's remaining certificate authorities in its root store.
The company said its certificate revocation and status services would remain operational until every SSL/TLS certificate it had issued had expired or been replaced. Its other businesses, including digital signature certificates, eSign and the CertiNext platform used by InCommon, will continue operating.
The announcement did not mention InCommon or clarify whether eMudhra would continue issuing new certificates under the G1 hierarchy until its exit from the global SSL/TLS business.
eMudhra said the global SSL/TLS business contributes approximately 1% of its revenue. According to the company, data sovereignty and compliance requirements make the business more complex and expensive to operate, while some large providers offer certificates free of charge.
The company also said the incident's spread on social media had brought "scrutiny that is out of proportion to SSL/TLS’s place in our business."
The researcher reported the weak private keys to Apple, Google, Microsoft, Mozilla and eMudhra on October 17. Each private key should have been a large random number, but all eight recovered keys were below 256, allowing anyone to calculate them almost instantly.
Chrome and Firefox blocked the six affected TLS intermediate certificates within hours. Google said no website certificate issued by those intermediates had appeared in Certificate Transparency logs before Chrome blocked them. Consequently, none could have been used against Chrome or other software that requires CT logging.
eMudhra said it had never used the eight certificates to issue certificates to websites or users and that its systems had not been breached.
The incident has prompted universities and other certificate holders to seek alternatives and assess whether their existing certificates remain trusted.
Cornell University has advised its certificate holders to request RSA certificates rather than ECC certificates, explaining that "RSA certificates use eMudhra's unaffected root and should work." The university has more than 300 of its own affected certificates.
The University of Michigan said InCommon's RSA certificates were not currently affected, although their root "could become distrusted, too." For the time being, the university identified Let's Encrypt as its main alternative.
eMudhra has estimated that approximately 30,000 certificates need to be migrated, with about 97% issued through ACME, the protocol widely used by servers to request and renew certificates automatically.
Chrome has informed eMudhra that standard ACME clients do not replace certificates outside their renewal windows unless they support ACME Renewal Information (ARI) or an operator intervenes manually. Moving certificates from the ECC hierarchy to the RSA hierarchy may also require changes to client settings.
Questions have also emerged about the integrity of eMudhra's RSA root hierarchy and its handling of certificate revocation lists.
On October 20, Mozilla said it was not removing trust in the G1 root, emSign Root CA - G1, for the time being. At Stanford University, InCommon certificates chain to that root through an eMudhra certificate authority called emSign Root TLS CA - G1.
On October 14, eMudhra published a certificate revocation list (CRL) for emSign Root TLS CA - G1. A CRL is a digitally signed list of certificates revoked by a certificate authority. The researcher who reported the weak keys said in Mozilla's public bug report that the signature on this list could not be verified against the certificate authority's own key.
A participant in the same bug report said on October 22 that the list appeared to have been signed using the key belonging to an eMudhra Online Certificate Status Protocol (OCSP) certificate. OCSP certificates sign responses indicating whether a certificate has been revoked. The participant said the match "appears to be a case of using the wrong signing key, rather than evidence of another weak key."
Chrome had raised the issue on October 21 as one of 12 questions posted to the bug report. It asked which key had signed the list and whether eMudhra held more than one key pair for that certificate authority or any of its root authorities.
Chrome also asked whether customers were migrating to G1, another company's certificate authority, or both, and when the migration would be completed in view of the planned October 27 removal of trust.
On October 20, eMudhra described G1 as "the only alternative available." The following day, the company said it was issuing affected customers in the United States fresh certificates "from an alternate, independently operated, publicly trusted CA hierarchy."
The current incident follows an earlier problem involving invalid revocation lists in 2025. That year, eMudhra published invalid CRLs for six of the same intermediate certificates. Its incident report at the time said the problem had been fixed by "regenerating the CRLs using the appropriate private key associated with each Intermediate CA."
On October 19, eMudhra told Mozilla that those lists had initially been signed with the keys intended for use. When the resulting signatures proved invalid, the lists were "resigned with flawed keys"—the weak keys discovered this month.
Chrome said the disclosure "raises serious concerns regarding eMudhra's transparency and incident handling" during and after the 2025 incident. It also asked why the earlier report had not disclosed that two key pairs existed for each of the affected certificate authorities.
As of 13:31 UTC on Thursday, eMudhra had not publicly answered any of Chrome's questions in the bug report. The company's most recent visible comment there was posted on October 20.
The withdrawal of eMudhra's global SSL/TLS certificate business, combined with the planned removal of trust in its ECC root, leaves thousands of certificate holders facing migration requirements while questions remain about the company's certificate management practices. Although eMudhra says its other services will continue and that it did not use the compromised intermediates to issue website or user certificates, the transition's timeline, the future status of its G1 hierarchy and the resolution of outstanding technical questions remain central to the incident.
About The Author
Comment List